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Abstract 

In  this  paper,  we  present  a  middleware  architecture  for  co¬ 
ordination  sendees  in  sensor  networks  that  facilitates  inter¬ 
action  between  groups  of  sensors  which  monitor  different 
environmental  events.  It  sits  on  top  of  the  native  routing 
infrastructure  and  exports  the  abstraction  of  mobile  com¬ 
munication  endpoints  maintained  at  the  locations  of  such 
events.  A  single  logical  destination  is  created  and  main¬ 
tained  for  every  environmental  event  of  interest.  Such  desti¬ 
nations  are  uniquely  labeled  and  can  be  used  for  communi¬ 
cation  by  application-level  algorithms  for  coordination  and 
sensory  data  management  between  the  different  event  lo¬ 
cales.  For  example,  they  may  facilitate  coordination,  in  a 
distributed  intrusion  scenario,  among  nodes  in  the  vicinity 
of  the  intruders. 

We  evaluate  our  middleware  architecture  using  GloMoSim, 
a  wireless  network  simulator.  Our  results  illustrate  the  suc¬ 
cess  of  our  architecture  in  maintaining  event-related  com¬ 
munication  endpoints.  We  provide  an  analysis  of  how  archi¬ 
tectural  and  network  dependent  parameters  affect  our  per¬ 
formance.  Additionally  we  provide  a  proof  of  concept  im¬ 
plementation  on  a  real  sensor  network  testbed  ( Berkeley’s 
MICA  Motes). 

1  Introduction 

The  impending  proliferation  of  sensor  networks  calls  for 
new  services  and  middleware  for  distributed  deeply  embed¬ 
ded  computing.  We  consider  ad  hoc  networks  formed  by 
dropping  wireless  computationally-equipped  sensors  (e.g., 
from  an  airplane)  onto  a  dangerous  or  inaccessible  infras¬ 
tructureless  environment  such  as  a  disaster  area  or  a  hostile 
territory  behind  enemy  lines.  The  lack  of  an  infrastructure 
implies  that  no  workstations  or  other  centralized  computing 
equipment  are  present  for  management  or  information  pro¬ 
cessing  purposes.  Such  sensor  networks  will  therefore  have 
to  host  their  own  distributed  embedded  computation.  They 
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will  execute  their  mission  autonomously  while  interacting 
with  spatially  distributed  external  events  in  the  physical  en¬ 
vironment.  (In  this  paper,  an  environmental  event  refers  to 
an  ongoing  activity,  such  as  the  motion  or  presence  of  a 
vehicle,  that  persists  in  the  physical  world  for  some  contin¬ 
uous  interval  of  time.) 

A  new  distributed  computing  paradigm  is  needed  to  sup¬ 
port  the  writing  and  execution  of  distribution  applications 
for  such  networks.  Due  to  the  tight  coupling  between  com¬ 
putation  in  the  sensor  network  and  events  in  the  environ¬ 
ment,  one  key  requirement  of  such  a  paradigm  is  to  suuport 
applications  that  coordinate  teams  of  sensor  and  actuator 
nodes  in  the  vicinity  of  different  external  events  of  inter¬ 
est.  For  example,  one  may  want  to  exchange  data  among  all 
nodes  in  the  vicinity  of  hostile  targets  in  the  sensor  field  to 
determine  a  plan  of  attack. 

The  aforementioned  coordination  problem  offers  an  inter¬ 
esting  research  challenge  to  the  communication  subsystem 
pertaining  to  mobility.  In  PDAs  and  Wireless  LANs,  sup¬ 
porting  mobility  typically  refers  to  maintaining  connectiv¬ 
ity  between  individual  devices  despite  their  changing  spa¬ 
tial  relationship  to  one  another.  In  contrast,  what  moves  in 
our  scenario  are  the  external  environmental  events.  Sensor 
network  nodes  themselves  remain  relatively  motionless.  In 
this  paper,  we  present  middleware  that  allows  programmers 
to  think  of  mobile  external  events  in  terms  of  abstract  persis¬ 
tent  entities  that  logically  form  in  the  network  as  a  response 
to  appropriate  sensor  readings.  The  middleware  forms  and 
maintains  a  unique  entity  around  each  event.  These  enti¬ 
ties  are  addressable  and  act  as  communication  destinations 
(end-points).  Note  that  we  define  an  event  as  something 
in  the  environment  that  causes  a  sensor  to  report  a  certain 
reading  (e.g.  fire,  moving  vehicle,  etc.)  and  an  entity  as  the 
abstract  addressable  equivalent  of  this  event  as  referenced 
by  the  programmer. 

The  communication  problem  is  therefore  to  maintain  the 
abstraction  of  transport-layer  connections  between  differ¬ 
ent  entities,  when  each  entity  is  composed  of  a  changing  set 
of  sensor  nodes  at  the  location  of  a  mobile  external  event. 
Such  mapping  is  made  complicated  by  several  factors.  One 
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is  the  need  for  seamless  end-point  migration  across  nodes 
as  the  event  moves.  Another  is  that  sensor  nodes  that  be¬ 
come  aware  of  an  external  event  should  be  able  to  decide 
whether  it  is  the  same  event  previously  seen  by  other  sen¬ 
sors  or  a  new  event.  Otherwise,  an  incorrect  event  list  will 
be  collectively  maintained  or  an  incorrect  mapping  will  re¬ 
sult  between  events  and  communication  endpoints.  This 
paper  reports  a  communication  architecture  which  resolves 
these  challenges. 

Our  middleware  hides  the  details  of  sensor  group  formation 
around  environmental  events,  end-to-end  connection  estab¬ 
lishment  between  different  entities,  and  entity  maintenance 
to  ensure  that  a  single  abstract  entity  is  created  and  main¬ 
tained  for  every  event  of  interest  in  the  environment.  This 
architecture’s  ability  to  ensure  a  one  to  one  relationship  be¬ 
tween  abstract  entities  and  environmental  events  simplifies 
communication,  facilitates  coordination,  and  reduces  pro¬ 
gramming  complexity  by  providing  communication  with 
persistent  entities  instead  of  dynamically  changing  sets  of 
individual  nodes. 

Our  techniques  are  geared  for  the  case  where  events  are  rea¬ 
sonably  sparse,  i.e.,  the  tracked  environmental  targets  are 
generally  not  in  close  proximity.  Disambiguating  nearby 
targets  is  an  inherently  difficult  problem  that  is  not  ad¬ 
dressed  in  this  paper.  The  reader  may  want  to  think  of 
our  architecture  as  imposing  a  resolution  constraint.  Tar¬ 
gets  that  are  closer  than  the  available  resolution  cannot  be 
individually  distinghuished.  As  we  shall  see  later,  the  res¬ 
olution  is  of  the  order  of  the  communication  radius  of  the 
sensor  nodes.  In  the  physical  sensor  node  prototype  avail¬ 
able  to  the  authors  this  radius  can  be  adjusted  from  several 
inches  to  hundreds  of  feet. 

The  remainder  of  this  paper  is  organized  as  follows.  We 
review  related  work  in  Section  2.  An  overview  of  entity 
establishment  and  maintenance  as  well  as  details  of  the  un¬ 
derlying  protocols  follows  in  Section  3.  Detailed  simulation 
results  are  discussed  in  Section  4.  A  description  of  an  im¬ 
plemented  proof-of-concept  prototype  is  given  in  Section  5. 
Finally,  we  explore  future  work  and  conclude  in  Section  6. 

2  Related  Work 

Sensor  networks  [11]  have  recently  emerged  as  a  promis¬ 
ing  platform  for  a  myriad  of  distributed  embedded  appli¬ 
cations  in  defense  [42]  and  scientific  exploration  [21].  A 
typical  sensor  network  is  highly  distributed  and  composed 
of  thousands  to  hundreds  of  thousands  of  individual  nodes. 
Communication  protocols  are  therefore  a  very  important  re¬ 
search  topic  in  sensor  networks. 

Most  prior  work  on  communication  in  sensor  networks  has 
focused  on  the  lower  layers  in  the  protocol  stack.  For  ex¬ 
ample,  [41,  45]  propose  MAC  layer  protocols  designed  for 
sensor  networks.  At  the  network  layer,  protocols  such  as 


DSDV  [27],  DSR  [14],  AODV  [29]  and  TORA  [25]  have 
gained  popularity  as  routing  solutions  for  ad  hoc  wireless 
networks.  While  these  protocols  are  designed  for  networks 
with  identifier-based  node  addressing,  recent  sensor  net¬ 
work  research  suggests  alternative  addressing  schemes  that 
do  not  rely  on  having  destinations  with  specific  identities. 
Instead,  it  has  been  proposed  that  routing  in  sensor  net¬ 
works  be  attribute-based  where  the  destination  is  reached 
by  its  attributes  such  as  location  or  sensor  measurements. 
For  example,  LAR  [17]  and  DREAM  [3]  propose  location- 
aware  routing  protocols,  where  the  destination  is  implic¬ 
itly  defined  by  its  physical  location.  Directed  diffusion 
[13]  and  the  intentional  naming  system  [1]  provide  rout¬ 
ing  and  addressing  based  on  data  interests.  A  related  effort 
is  attribute-based  naming  [32],  proposed  for  an  Internet  en¬ 
vironment,  which  allows  queries  to  be  routed  depending  on 
the  requested  content  rather  than  on  the  identity  of  the  target 
machine.  Our  work  falls  in  the  general  category  of  attribute- 
based  communication.  We  provide  an  infrastructure  where 
communication  end-points  are  placed  at  the  locations  of 
specific  events  in  the  environment.  Unlike  prior  work  on 
attribute-based  addressing,  we  focus  on  protocol  dynamics 
that  arise  due  to  the  motion  of  such  events  in  the  external 
world.  We  aim  to  maintain  the  persistence  and  uniqueness 
of  these  communication  end-points  as  the  event  moves  and 
discuss  factors  that  affect  the  maximum  trackable  speed  of 
these  events.  Also,  unlike  routing-layer  approaches,  our  ar¬ 
chitecture  sits  in  the  transport  layer  on  top  of  geographic 
forwarding. 

Mobile  end-points  have  been  addressed  in  traditional  and  ad 
hoc  computer  networks.  For  example.  Energy-aware  rout¬ 
ing  protocols  were  proposed  such  as  Span  [6]  and  GAF  [43] 
for  communication  between  mobile  nodes.  In  Mobile  IP 
[26],  mobile  hosts  are  free  to  migrate  between  LAN’s  while 
they  remain  connected  by  a  home  agent  residing  at  their 
home  address.  Another  mechanism  for  maintaining  mobile 
connections  uses  DNS  to  provide  the  indirection  necessary 
to  support  mobility  [34],  We  address  mobility  in  a  dif¬ 
ferent  sense  in  our  protocol.  Whereas  the  aforementioned 
protocols  assume  moving  nodes  and  provide  for  commu¬ 
nication  between  these  moving  nodes,  we  assume  static 
nodes  but  moving  events  (and  thus  entities)  in  our  system 
and  provide  a  migratory  end-point  infrastructure  for  com¬ 
munication  between  these  moving  entities.  A  recent  proto¬ 
col  TTDD  [44],  addresses  communication  between  moving 
sources  and  sinks  in  a  sensor  network.  Our  work  differs 
from  this  in  the  fact  that  we  provide  for  the  creation  and 
maintenance  of  abstract  entities  to  facilitate  communication 
between  moving  events  in  the  network.  Also,  our  commu¬ 
nication  end-points  are  bi-directional  as  opposed  to  being 
statically  designated  as  sources  or  sinks. 

Several  algorithms  exist  that  provide  clustering  and  vari¬ 
ous  granular  levels  of  group  formation  on  both  the  network 
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and  application  layers.  The  (a,  t)  framework  [22,  37],  and 
Landmark  Hierarchy  [39]  organize  nodes  into  hierarchical 
groups  as  a  solution  to  routing.  LEACH  [10],  ASCENT  [5], 
SPAN  [6],  and  GAF  [43]  form  groups  or  share  data  locally 
to  conserve  energy  and  power  down  unused  or  unneeded 
nodes.  The  AC  Hierarchy  [7,  8,  38]  forms  hierarchical  clus¬ 
ters  covering  the  entire  sensor  network  and  provides  a  high 
level  programming  abstraction  for  division  or  simplification 
of  the  sensor  network.  Finally,  GLS  [19]  and  MASH  [33] 
provide  cluster  based  location  or  query  services  for  locating 
data  or  nodes.  Unlike  these  cluster  or  group  based  algo¬ 
rithms  we  provide  the  abstraction  of  tracking  groups  linked 
directly  to  environmental  events  of  interest.  While  some 
of  these  algorithms  such  as  GLS  could  be  used  in  paral¬ 
lel  with  our  work  for  object  lookup,  and  while  various  ideas 
from  these  protocols  are  similar  or  could  be  used  to  enhance 
the  efficiency  or  functionality  of  our  modules,  none  provide 
sufficient  support  for  entity  formation  around  environmen¬ 
tal  events  of  interest  and  end-to-end  connection  establish¬ 
ment  and  maintenance  between  moving  entities. 

Our  work  is  also  complementary  to  several  research  efforts 
that  aim  to  provide  new  abstractions  and  paradigms  for  dis¬ 
tributed  computing  in  sensor  networks.  For  example,  Mag- 
netOS  [2],  exports  the  illusion  of  a  single  Java  virtual  ma¬ 
chine  on  top  of  a  distributed  sensor  network.  The  applica¬ 
tion  programmer  writes  a  single  Java  program.  The  run¬ 
time  system  is  responsible  for  code  partitioning,  placement, 
and  automatic  migration  such  that  total  energy  consumption 
is  minimized.  Mate  [18]  is  another  example  of  a  virtual  ma¬ 
chine  developed  for  sensor  networks.  It  implements  its  own 
bytecode  interpreter,  built  on  top  of  TinyOS  [11].  The  in¬ 
terpreter  provides  high-level  instructions  (such  as  an  atomic 
message  send)  which  the  machine  can  interpret  and  execute. 

To  the  authors’  knowledge,  the  communication  architecture 
proposed  in  this  paper  is  the  first  that  provides  middleware 
support  to  tracking  applications  for  group  formation  around 
environmental  events,  end-to-end  connection  establishment 
between  different  entities,  and  abstract  entity  maintenance 
to  ensure  that  a  single  entity  is  formed  and  maintained  for 
every  event  in  the  environment.  The  architecture  ensures 
a  one  to  one  relationship  between  abstract  entities  and  en¬ 
vironmental  events  thus  simplifying  communication,  and 
reduces  programming  complexity  by  allowing  communica¬ 
tion  with  entities  rather  than  individual  nodes. 

3  Service  Architecture 

The  ability  of  a  sensor  network  to  closely  interact  with  the 
environment  in  which  it  has  been  deployed  gives  rise  to  a 
multitude  of  applications  in  which  code  execution  is  tightly 
linked  to  the  locations  of  environmental  events.  Appropri¬ 
ate  communication  abstractions  are  required  to  isolate  dis¬ 
tributed  application  programmers  from  accounting  for  the 


changing  locations  of  environmental  events  in  the  vicinity 
of  which  the  communication  end-points  of  their  applica¬ 
tions  are  located.  Our  architecture  provides  such  abstrac¬ 
tions  by  a  combination  of  (i)  a  team  management  frame¬ 
work  for  maintaining  proper  mapping  between  communi¬ 
cation  endpoints  and  external  events  (ii)  a  transport  layer 
protocol  for  communication  among  event-related  endpoints. 
Together,  they  maintain  communication  end-points  associ¬ 
ated  with  mobile  external  events,  as  well  as  maintain  con¬ 
nectivity  among  such  endpoints.  This  architecture  is  in¬ 
dependent  of  the  underlying  radio,  data  link,  and  network 
layer  protocols  making  it  applicable  in  principle  to  an  array 
of  sensor  network  platforms. 

Such  programming  abstractions  are  desired  in  applications 
where  one  wishes  to  interact  with  physical  events  in  the  en¬ 
vironment  that,  for  one  reason  or  another,  do  not  commu¬ 
nicate  directly  with  the  network.  By  forming  an  abstract 
entity  that  moves  with  the  event,  we  can  associate  state  and 
behavior  with  the  physical  event.  For  a  hostile  target  being 
tracked,  this  state  and  behavior  could  include  monitoring 
the  number  of  shots  fired  from  a  tank  or  the  distance  an  ob¬ 
ject  has  travelled. 

3.1  The  Entity  Communication  Problem 

The  problem  addressed  by  our  architecture  is  more  formally 
described  as  follows.  We  consider  a  dynamically  changing 
set  S  of  events  in  the  physical  environment  of  the  sensor 
network.  Let  the  physical  location  of  each  event  Ei  £  S  at 
time  t  be  denoted  Li(t).  A  node  is  said  to  be  in  the  vicinity 
of  event  Ei  at  time  t  if  it  is  within  sensor  range  of  the  event’s 
location,  Li(t).  In  this  paper,  we  assume  that  environmen¬ 
tal  events  are  localized,  i.e.,  their  location  is  described  by  a 
single  point  in  space,  as  opposed  to  an  area.  This  definition 
applies  to  tracking  vehicles,  finding  survivors,  monitoring 
wild  animals,  or  detecting  localized  fires.  We  assume  that 
events  can  be  detected  independently  by  individual  nodes  in 
the  sensor  network  based  on  their  local  measurements.  For 
example,  detecting  a  magnetic  signature  in  a  desert  battle 
area  would  usually  be  indicative  of  a  passing  armored  ve¬ 
hicle.  Finally,  we  assume  that  events  are  sparse.  In  other 
words,  the  signatures  of  different  targets  are  generally  not 
overlapping. 

Let  Tj  denote  the  set  of  nodes  in  the  vicinity  of  event  E,  . 
The  objective  of  our  architecture  is  to  maintain  a  unique  ad¬ 
dressable  destination  associated  with  each  event  Ei,  such 
that  sending  data  to  it  causes  delivery  of  this  data  to  Ti  re¬ 
gardless  of  the  location  Li(t). 

In  the  above  problem  statement,  we  define  delivery  of  a 
message  to  T,  as  delivery  of  the  message  to  the  current  en¬ 
tity  leader  who  by  definition  belongs  to  the  set  Ti.  What 
the  leader  does  with  the  message  is  an  orthogonal  issue  in 
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our  architecture.  Also  note  that  once  the  aforementioned 
problem  is  solved,  it  becomes  trivial  to  associate  multiple 
communication  end-points  with  each  entity  simply  by  de¬ 
multiplexing  the  received  message  based  on  a  port  number 
in  the  message  header,  in  the  same  sense  that  UDP  creates 
multiple  ports  over  IP. 

3.2  Sensor  Network  Assumptions 

Our  underlying  sensor  network  typically  consists  of  thou¬ 
sands  of  small  sensor  nodes  thrown  arbitrarily  (e.g.,  from 
the  air)  onto  a  large  target  area,  such  as  a  battlefield  or 
the  scene  of  a  natural  disaster.  Individual  nodes  have  re¬ 
source  limitations  associated  with  small  physical  size  in¬ 
cluding  low-power  batteries,  relatively  slow  processors,  and 
limited  memories.  They  are  capable  of  wireless  commu¬ 
nication  and  once  deployed  form  a  large-scale  ad-hoc  net¬ 
work.  A  key  assumption  is  that  the  formed  sensor  network 
has  no  pre-existent  infrastructure  or  centralized  services. 
It  is  precisely  the  difficulty  of  creating  such  an  infrastruc¬ 
ture  in  harsh  or  inaccessible  environments  that  motivates 
the  sensor  network  approach.  An  example  of  computation¬ 
ally  equipped  wireless  sensor  devices  that  meet  the  above 
description  is  the  MICA  mote  [12],  which  we  use  in  our 
experimental  prototype. 

Once  deployed,  nodes  in  a  sensor  network  are  assumed  to 
establish  their  location  and  remain  motionless  except  due 
to  environmental  factors  such  as  wind  and  water.  In  an  im¬ 
portant  departure  from  the  typical  mobile  ad  hoc  wireless 
network  model,  nodes  in  sensor  network  literature  do  not 
have  IP-address,  and  do  not  run  the  TCP/IP  protocol  suite. 
Instead  of  possessing  unique  ID’s,  sensor  network  nodes 
are  usually  referenced  by  attributes  such  as  location.  Both 
localization  services  [4,  30]  that  establish  sensor  network 
coordinate  frameworks,  and  location-based  routing  services 
[17,  3]  that  route  messages  geographically  have  been  dis¬ 
cussed  at  length  in  previous  literature. 

Sensor  nodes  may  perform  local  processing  as  appropri¬ 
ate  for  their  particular  application.  This  could  be  aggregat¬ 
ing  and  reporting  raw  data,  triangulating  the  position  of  an 
event,  coming  to  agreement  about  an  actuation  or  reporting 
strategy,  or  performing  distributed  event  analysis.  A  dis¬ 
tributed  application,  such  as  a  distributed  intrusion  response 
system,  may  need  to  pass  the  results  of  such  local  process¬ 
ing  among  the  respective  groups  of  sensors  to  coordinate  a 
sensor  network  reaction. 

Our  service  can  be  thought  of  as  a  distributed  protocol 
that  sits  in  the  transport  layer  of  the  sensor  node’s  proto¬ 
col  stack.  In  its  basic  form,  the  protocol  implementation 
consists  of  two  modules,  namely,  the  entity  management 
module  (EMM),  and  the  entity  connection  module  (ECM). 
These  modules  are  shown  in  Figure  1.  As  the  name  sug¬ 


gests,  the  EMM  forms  a  local  entity  in  response  to  sen¬ 
sor  readings  at  the  locations  of  environmental  events.  It 
maintains  the  unique  identity  of  this  entity  as  the  event  of 
interest  migrates  in  the  environment.  The  ECM  provides 
a  means  for  entity  registration,  maintains  communication 
end-points,  and  provides  connectivity  to  allow  communica¬ 
tion  among  different  entities.  The  following  sections  dis¬ 
cuss  the  details  of  the  APIs  and  implementations  of  the 
aforementioned  modules. 


Figure  1.  Service  Architecture 


3.3  Entity  Management  Module 

The  entity  management  module  (EMM)  provides  an  entity 
formation  and  maintenance  service.  The  EMM  has  sev¬ 
eral  essential  functions.  First,  an  entity  must  be  created 
and  identified  when  an  event  first  occurs  in  the  sensor  net¬ 
work.  Second,  once  established,  the  EMM  must  maintain 
this  single  entity  and  prevent  spurious  entities  from  form¬ 
ing  around  a  previously  abstracted  event.  While  an  entity 
exists  the  EMM  must  maintain  its  persistent  state  such  as 
its  unique  identity  which  signifies  the  local  environmental 
event.  Finally,  the  EMM  is  responsible  for  ensuring  that 
nodes  that  sense  an  event  for  the  first  time  know  when  to 
become  a  member  of  an  existing  entity  and  when  to  spawn 
a  new  entity  around  the  sensed  event.  These  functions  are 
described  below. 

3.3.1  Functional  Overview 

At  any  given  time,  multiple  events  in  the  environment  give 
rise  to  multiple  entities  which  host  the  communication  end¬ 
points  in  the  sensor  network.  An  entity  is  a  set  of  nodes 
in  the  vicinity  of  a  single  environmental  event.  We  call 
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nodes  whose  sensors  detect  the  signature  of  the  correspond¬ 
ing  event,  entity  members.  These  nodes  are  said  to  be  within 
the  sensory  horizon  of  the  target  event.  To  the  rest  of  the 
sensor  network,  an  entity  acts  as  a  single  whole.  The  fact 
that  the  entity  may  consist  of  multiple  nodes  is  hidden  and 
the  identities  of  these  nodes  are  abstracted  away. 

Entity  members  volunteer  to  be  an  entity  leader ,  a  cen¬ 
tral  node  responsible  for  communication  and  group  main¬ 
tenance,  as  well  as  running  entity-specific  application  code. 
Once  the  entity  leader  no  longer  detects  the  event,  it  hands- 
off  leadership  (and  current  state)  to  another  node  by  sending 
a  relinquish  leadership  message.  As  the  event  migrates  or 
expands,  the  leadership  handoff  mechanism  built  into  the 
EMM  ensures  that  the  entity  and  its  stored  application  state 
migrate  with  it.  The  application  on  a  node  is  informed  when 
the  node  becomes  a  leader  so  that  it  can  pick  up  computa¬ 
tion  from  where  the  previous  leader  left  it.  The  application 
is  also  notified  when  the  node  ceases  to  be  leader. 

A  key  requirement  is  to  ensure  that  only  one  entity  is 
spawned  for  the  same  environmental  event.  The  EMM  pro¬ 
tocol  achieves  this  requirement  by  announcing  the  existence 
of  an  entity  to  nearby  nodes  within  a  distance  called  the 
awareness  horizon.  By  design,  the  awareness  horizon  is 
larger  than  the  sensory  horizon.  Nodes  in  the  awareness 
horizon  that  cannot  sense  the  event  are  called  entity  follow¬ 
ers,  as  distinguished  from  entity  members.  These  nodes  are 
prevented  from  spawning  new  entities. 

Figure  2  shows  nodes  in  their  corresponding  role.  The  en¬ 
vironmental  event  is  located  at  the  E  and  has  a  radial  dis¬ 
tance  specified  by  the  dotted  line.  The  node  in  the  center  of 
the  darkest  region  is  the  entity  leader.  Nodes  within  sens¬ 
ing  radius  of  the  event  are  entity  members  while  nodes  out¬ 
side  this  area  that  are  within  the  awareness  horizon  become 
entity  followers.  Note  that  while  the  sensory  horizon  and 
awareness  horizon  are  shown  as  circles  for  clarity,  we  do 
not  make  nor  use  this  uniform  radius  assumption  in  the  al¬ 
gorithm.  In  fact,  in  most  cases  these  horizons  will  have  an 
amorphous  boundary. 
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Figure  2.  A  team  forms  around  a  detected 
event 


Figure  3.  Node  state  transition  diagram 

Note  that,  while  inhibiting  entity  followers  from  creating 
new  entities  is  essential  for  preventing  redundant  reppresen- 
tation  of  the  same  target,  it  has  one  unfortunate  side  effect. 
Namely,  the  mechanism  may  prevent  nodes  from  reporting 
secondary  events  in  the  vicinity  of  events  already  reported. 
Since,  we  assume  that  events  are  sparse,  the  hope  is  that 
cases  like  the  above  are  not  common. 


3.3.2  Entity  Uniqueness 


Nodes  join  the  awareness  horizon  upon  the  reception  of  a 
bounded-hop  broadcast  ( heartbeat )  from  the  nearby  EMM 
leader.  Upon  receiving  a  heartbeat,  a  node  sets  a  corre¬ 
sponding  entity  timeout  timer.  The  node  ceases  to  be  a  fol¬ 
lower  when  the  timer  expires.  The  timer  is  re-initialized 
upon  the  receipt  of  each  new  heartbeat.  If  the  node  senses 
the  event  signature  before  the  entity  timeout  timer  expires  it 
becomes  a  member  of  the  existing  entity.  If  the  timer  had 
already  expired  the  node  is  no  longer  a  follower  and  will 
create  a  new  entity.  This  mechanism  prevents  multiple  enti¬ 
ties  from  being  spawned  for  the  same  environmental  event. 
Figure  3  depicts  the  node  state  transition  diagram  between 
follower,  member,  and  leader  states,  as  well  as  the  free  state 
in  which  a  node  is  not  cognizant  of  any  entities. 


Entity  uniqueness  is  the  algorithm  property  that  states  that 
only  one  entity  is  associated  with  any  given  environmental 
event.  In  this  section,  we  take  a  closer  look  at  the  conditions 
under  which  this  property  holds  true.  In  general,  there  are 
two  cases  in  which  entity  uniqueness  can  be  compromised. 
The  first  case  occurs  at  excessive  target  speeds.  If  the  target 
moves  in  the  environment  fast  enough,  far  apart  nodes  can 
detect  it  at  about  the  same  time  and  create  independent  enti¬ 
ties  to  represent  it.  The  second  case  occurs  due  to  message 
loss  or  node  failures  which  may  prevent  proper  leadership 
handoff.  Consequently  a  new  leader  may  emerge  that  does 
not  inherit  the  right  entity  identity  from  the  old  leader,  caus¬ 
ing  a  different  entity  to  emerge  for  the  same  connection.  In 
the  following,  we  quantify  the  maximum  event  speed  that 
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preserves  entity  uniqueness  and  discuss  provisions  to  en¬ 
sure  robustness  in  the  face  of  failures. 

Event  Speed:  The  key  rule  which  inhibits  creation  of  du¬ 
plicate  entities  for  the  same  event  is  that  followers  of  exist¬ 
ing  entities  cannot  spawn  new  entities.  Instead,  when  they 
eventually  sense  the  event,  they  must  join  the  membership 
of  the  entity  of  which  they  were  followers.  By  extending 
awareness  of  the  event  (i.e.,  the  awareness  horizon)  beyond 
its  sensory  horizon  we  can  ensure  that  new  nodes  will  al¬ 
ways  become  aware  of  the  current  entity  before  they  sense 
the  event.  Hence,  a  single  unique  entity  will  exist  for  each 
event  in  the  environment.  The  above  uniqueness  property  is 
violated  only  if  the  event  moves  fast  enough  in  the  environ¬ 
ment  such  that  it  is  sensed  by  nodes  outside  of  the  aware¬ 
ness  horizon  before  information  of  this  event  is  propagated 
to  them.  Controlling  the  awareness  horizon  therefore  de¬ 
termines  the  maximum  tolerable  event  velocity  as  will  be 
detailed  below. 

Note  that  a  new  leader  is  elected  once  the  old  one  stops  sens¬ 
ing  the  target.  This  new  leader  will  cause  the  center  of  the 
awareness  horizon  to  shift  to  its  new  location.  If  leader  re- 
election  and  heartbeat  propagation  took  zero  time,  the  sys¬ 
tem  could  theoretically  track  infinitely  fast  targets  as  long 
as  the  awareness  horizon  was  at  least  double  the  sensory 
horizon.  This  is  because  the  current  leader  would  always 
be  within  sensor  radius  from  the  target  and  no  other  node 
within  the  sensory  horizon  could  be  more  than  twice  the 
sensor  radius  away  from  the  leader.  Hence,  all  nodes  who 
sense  the  target  are  always  within  the  awareness  horizon 
and  are  therefore  inhibited  from  creating  new  entities.  In 
reality,  however,  leader  re-election  and  heartbeat  propaga¬ 
tion  take  time.  If  the  maximum  combined  leader  re-election 
and  heartbeat  propagation  delay  was  D,  it  is  easy  to  show 
that  the  maximum  speed  that  preserves  entity  uniqueness  is 
(awareness  horizon  —  2  •  sensory  horizon) / D.  It  should 
be  noted  that  the  above  is  a  conservative  estimate.  Entity 
uniqueness  will  not  be  compromised  immediately  at  higher 
target  speeds. 

Robustness  to  Message  Loss  and  Failure:  To  prevent 
handoff  failure  in  the  case  that  an  entity  leader  dies  or  other¬ 
wise  fails  to  send  out  the  relinquish  heartbeat  message,  each 
entity  member  sets  a  failed  leader  tinier.  This  timer,  upon 
expiration,  prompts  an  entity  member  to  assume  the  entity 
leader  role  and  begin  sending  heartbeats  after  an  additional 
random  delay  (to  prevent  simultaneous  takeover  collisions). 
This  failed  leader  timer  must  be  set  to  a  value  larger  than  the 
heartbeat  period,  the  interval  between  heartbeats,  to  ensure 
that  timer  expiration  does  not  occur  prematurely  while  the 
current  leader  is  still  alive.  Depending  on  expected  message 
loss,  one  might  also  set  this  timer  to  a  value  greater  than  two 
or  three  times  the  heartbeat  period  to  prevent  inopportune 
and  premature  handoff  when  heartbeats  are  lost  or  subject 
to  collisions.  Note  the  delay  that  a  node  waits  before  assum¬ 


ing  the  entity  leader  role  could  be  determined  in  accordance 
with  the  strength  of  a  node’s  sensor  reading,  whether  or  not 
this  sensor  reading  is  growing  or  shrinking  in  strength,  the 
number  of  entity  members  that  are  direct  neighbors  of  that 
node,  or  by  some  other  appropriate  metric. 

Message  loss  can  also  prevent  nodes  within  the  awareness 
horizon  from  getting  the  leader’s  heartbeats.  Consequently, 
these  nodes  may  not  become  aware  of  the  entity  and  may 
create  a  spurious  one  when  they  sense  the  event.  To  kill 
such  spurious  entities,  we  employ  a  mechanism  that  asso¬ 
ciates  larger  weights  with  older  entities  and  biases  nodes 
against  joining  entities  with  smaller  weights.  The  mecha¬ 
nism  maintains  an  alive  counter  at  the  leader  of  each  entity. 
This  counter  is  propagated  through  heartbeats  and  its  value 
is  accumulated  across  leader  handoffs.  When  a  new  entity 
is  first  created,  its  counter  is  initialized  to  0.  This  value  is 
then  incremented  for  each  heartbeat  sent  out  and  is  there¬ 
fore  a  reflection  of  how  long  the  entity  has  remained  in  the 
network.  When  a  node  tries  to  spawn  a  new  entity,  every 
neighbor  that  is  already  part  of  an  entity  with  a  higher  alive 
counter  ignores  the  new  node.  Hence,  the  faulty  node  is  iso¬ 
lated.  The  mechanism  will  send  a  kill  message  to  the  faulty 
node  to  request  termination  of  its  spurious  entity. 

The  above  mechanism  serves  to  prevent  spurious  groups 
from  forming  in  the  presence  of  message  loss,  but  unfor¬ 
tunately  fails  to  handle  the  case  where  events  of  the  same 
signature  migrate  across  one  another’s  path.  To  handle  this 
more  complex  scenario  we  define  a  compile  time  specified 
threshold,  min  time  alive,  to  ensure  entities  that  have  ex¬ 
isted  over  some  time  period  remain  after  crossing  paths  with 
an  even  older  entity.  When  a  node  of  entity  El  receives  a 
heartbeat  from  the  leader  of  another  entity  E 2  and  both  enti¬ 
ties  have  an  alive  counter  set  greater  than  the  min  time  alive 
threshold,  we  require  that  both  entities  coexist.  In  this  case, 
nodes  independently  apply  the  EMM  protocol  with  respect 
to  each  entity.  For  example,  they  may  be  within  the  aware¬ 
ness  horizon  of  multiple  entities  at  the  same  time.  When 
they  sense  the  event,  they  become  members  of  all  entities 
that  exceed  the  min  time  alive  threshold  of  which  they  are 
aware. 

3.4  Entity  Management  API 

The  API  exported  by  the  EMM  consists  of  join( signature ) 
and  leave(signature)  primitives  which  the  application  calls 
when  it  first  senses  or  stops  sensing  an  event  signature 
respectively.  The  code  of  the  signature  is  passed  as  the 
input  parameter  to  these  primitives.  For  example,  if  the 
magnetic  signature  of  a  vehicle  is  sensed,  the  node  calls 
join(Magnetic).  Unlike  traditional  group  communication, 
the  join()  does  not  take  a  group  identifier  as  input.  Instead, 
it  returns  as  output  the  identity  of  the  environmental  event 
the  application  just  sensed.  As  described  in  this  section,  this 
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identity  is  of  the  entity  for  which  the  node  was  a  follower  at 
the  time  join( )  was  called.  If  the  node  is  a  follower  of  mul¬ 
tiple  nodes,  a  list  of  identities  is  returned.  The  semantics 
are  that  the  node  has  joined  the  respective  list  of  entities.  If 
a  node  is  not  a  follower  of  any  entity,  a  new  entity  is  cre¬ 
ated  when  join()  is  called  and  the  code  of  the  new  entity  is 
returned. 

The  EMM  also  requires  the  application  to  implement  a  han¬ 
dler  for  an  upcall  called  leader(entity,on_off).  The  upcall 
contains  an  entity  id  as  a  parameter  as  well  as  a  boolean  that 
tells  the  application  that  its  node  has  just  become  or  ceased 
to  be  leader  of  the  named  entity.  Application  code  would 
typically  check  whether  it  is  the  leader  or  a  member,  and 
execute  the  corresponding  part  of  its  typically  distributed 
data  processing  algorithm  based  on  the  assigned  role. 

The  last  part  of  the  API  is  a  store( entity,  state)  and 
get( entity, state)  call  that  allows  the  application  on  the  leader 
node  to  save  and  retrieve  persistent  state  of  a  named  entity. 
The  entity  name  is  passed  as  input  parameter  to  the  call. 
Typically,  the  leader  would  save  its  state  after  each  itera¬ 
tion.  This  state  is  transmitted  in  the  EMM  heartbeats  to  all 
members  of  the  entity.  Upon  leader  handoff,  the  new  leader 
would  use  the  above  API  to  get  the  most  recent  previously 
communicated  state.  It  would  then  resume  the  iterative  ap¬ 
plication  from  that  point  onwards. 

3.5  Entity  Connection  Module 

The  entity  connection  module  (ECM)  provides  a  basic  end- 
to-end  location  and  communication  service  between  mobile 
entities.  ECM  is  therefore  the  equivalent  of  UDP  for  sensor 
networks,  with  the  exception  that  destinations  are  migratory 
entity  leaders,  not  IP  hosts.  An  application  can  utilize  the 
ECM’s  API  to  communicate  messages  to  and  from  logical 
entities  without  concern  for  where  that  entity  resides,  how 
it  is  maintained,  or  what  particular  nodes  compose  it.  An 
application  programmer  can  therefore  initiate  queries  and 
interact  with  environmental  events  that  migrate  throughout 
the  sensor  network. 

The  ECM  exports  a  subset  of  a  socket-like  API.  All  appli¬ 
cations  are  assumed  to  have  well-known  ports.  In  the  cur¬ 
rent  protocol  256  ports  are  supported  based  on  a  byte  in  the 
message  header.  We  do  not  support  dynamic  application-to- 
port  binding.  This  is  because  in  our  target  platform,  namely, 
Berkeley’s  MICA  motes  running  TinyOS,  applications  are 
structured  as  a  graph  of  permanently  wired  modules.  The 
ECM  demultiplexes  incoming  messages  as  upcalls  to  dif¬ 
ferent  application  modules  depending  on  their  port  number. 
The  association  of  port  numbers  and  upper  layer  modules  is 
defined  in  a  compile-time  configuration.  At  run-time  an  ap¬ 
plication  can  call  listenf)  to  notify  the  ECM  that  it  is  ready 
to  receive  messages  on  its  assigned  port.  Subsequently,  the 


ECM  propagates  messages  on  this  port  to  the  application. 
If  a  message  arrives  for  a  port  on  which  no  application  is 
listening,  the  message  is  dropped. 

Connections  are  identified  by  a  <Entity  ID,  Port  Num> 
pair.  When  an  entity  is  spawned,  entity  registration  is  in¬ 
voked  by  the  ECM.  This  registration  utilizes  a  directory 
service  similar  to  the  indirection  infrastructure  described 
in  [35].  Namely,  each  entity  maintains  replicated  pointers 
to  its  current  location  in  a  region  of  the  sensor  network  de¬ 
termined  by  a  hash  function.  The  hash  key  is  the  signature 
identifier  associated  with  the  entity.  By  hashing  this  key,  the 
ECM  can  determine  the  location  of  the  directory  region  as¬ 
sociated  with  a  particular  type  of  environmental  event,  then 
query  the  directory  for  all  entities  that  are  currently  follow¬ 
ing  events  of  that  type.  Queries  to  this  directory  service  sup¬ 
ply  entity  leader  information  pertinent  to  establishing  mo¬ 
bile  connections. 

When  connecting  with  an  entity,  the  ECM  looks  up  the  last 
known  entity  leader  based  on  the  <Entity  ID,  Port  Num> 
pair  provided  in  the  application  call.  If  this  information  is 
older  than  a  specified  threshold  the  directory  service  is  con¬ 
tacted  for  updated  information.  The  returned  last-known 
leader  is  used  as  a  connection  point  for  communication. 
Upon  receiving  a  message,  an  endpoint  updates  its  table  of 
last-known  leaders  with  that  contained  in  the  header.  The 
more  traffic  exchanged  between  the  endpoints,  the  more  up- 
to-date  the  leader  information  is. 

Leadership  information  is  retained  in  the  ECM  in  a  limited- 
size  table.  When  the  table  is  full,  replacement  is  done  on 
a  least-recently-used  basis.  The  ECM  of  an  entity  periodi¬ 
cally  refreshes  the  directory  region,  at  an  interval  called  the 
directory  refresh  rate  to  ensure  that  its  information  remains 
up  to  date.  In  addition,  past  followers  of  an  entity  remember 
the  location  of  the  last  known  leader  for  a  time  interval  that 
exceeds  the  directory  refresh  rate.  Hence,  messages  sent  to 
the  old  location  of  an  entity  are  forwarded  to  the  current 
location  when  they  intercept  the  entity’s  trail. 

4  Simulation 

To  fully  understand  and  validate  our  proposed  architecture, 
we  implement  our  design  in  GloMoSim  V2.03,  a  popular 
wireless  network  simulator.  GloMoSim  was  developed  as  a 
modular  library  of  components  that  contribute  to  an  exten¬ 
sible,  robust,  and  dynamic  simulation  of  wireless  networks. 
By  isolating  nodes’  communication  layers  into  independent 
modules,  GloMoSim  allows  researchers  to  “plug  and  play” 
different  protocols  (i.e.  protocols  that  they  develop  and  im¬ 
plement)  without  concern  for  the  inner  workings  of  other  ar¬ 
chitectural  layers.  The  simulation  environment  allows  us  to 
apply  our  modules  to  the  problem  of  event  tracking.  Specif¬ 
ically,  by  simulating  event  tracking  in  GloMoSim  using  our 
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EMM  and  ECM  modules,  we  are  able  to  analyze  the  effects 
of  architectural  parameters  on  performance  and  understand 
how  our  architecture  can  be  tuned  to  solve  real  world  track¬ 
ing  problems. 

4.1  Scenario 

We  modified  the  Transport  and  Application  layers  of  Glo- 
MoSim  to  simulate  a  hypothetical  sensor  network  environ¬ 
ment  consisting  of  nodes  communicating  over  a  220  meter 
radius,  which  is  typical  for  sensor  nodes.  The  lower  level 
protocols  of  our  wireless  network  include  Geographic  For¬ 
warding  [16]  over  IP  in  the  Network  layer  and  802.1  IB  in 
the  MAC  layer.  We  simulated  32  byte  packets  sent  in  a  200 
kbps  wireless  medium,  a  slightly  larger  bandwidth  than  the 
capabilities  of  today’s  sensor  devices  (50kbps-100kbps)  to 
account  for  future  improvements.  At  the  physical  layer,  we 
use  a  Two-Ray  Pathloss  model  with  SNR-Bounded  Noise 
at  the  receiving  node.  The  model  allows  noise,  attenuation, 
and  subsequent  loss  on  the  wireless  channel  to  be  simulated, 
as  opposed  to  perfect  reception  within  a  hypothetical  radius. 
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Node  Location  +  Actual  x  Reported  • 

Figure  4.  Simulated  1,400  X  1,400  meter  field 

Sensor  nodes  are  equipped  with  sensors  that  poll  their  envi¬ 
ronment  for  specific  events  (e.g.,  acoustic  sensors  that  mon¬ 
itor  and  can  recognize  certain  acoustic  signatures  such  as 
tank  movement).  In  our  experiments,  a  number  of  nodes  are 
uniformly  distributed  in  a  1,400  x  1,400  meter  field,  shown 
in  Figure  4. 

To  test  the  ability  of  our  architecture  to  track  a  moving 
target,  we  simulate  an  object  moving  across  the  field  in  a 
straight  line.  The  moving  object  is  tracked  (presumably  us¬ 
ing  acoustic  or  magnetic  sensors)  with  a  sensor  polling  pe¬ 
riod  of  0.05  seconds,  a  granularity  high  enough  to  ensure 
up  to  date  readings.  Sensors  register  a  target  up  to  a  sensing 


radius  of  approximately  100  meters.1 

For  our  tests  we  employ  a  simple  application  that  computes 
an  event’s  position  through  entity  member  reports  to  the  en¬ 
tity  leader.  Entity  members  poll  their  sensors  and  send  pe¬ 
riodic  updates  to  the  corresponding  entity  leader  notifying 
this  leader  of  their  current  sensor  reading  and  position.  The 
leader  computes  the  weighted  average  of  the  position  of  re¬ 
porting  entity  members.  The  weighting  is  by  sensor  reading 
since  higher  readings  presumably  mean  a  closer  target.  This 
average  value  is  sent  back  every  0.5  seconds  to  a  “friendly- 
force”  entity  at  a  static  location  in  the  network.  Upon  re¬ 
ceiving  a  report,  this  entity  responds  with  a  confirmation 
message  sent  back  to  the  reporting  entity.  This  feature  al¬ 
lows  us  to  test  our  architecture’s  ability  to  maintain  end-to- 
end  connectivity  and  forwarding  between  entities. 

4.2  Simulation  Results 

The  objective  of  our  simulation  is  to  understand  the  effect  of 
algorithm  parameters  on  tracking,  as  well  as  estimate  costs 
such  as  the  energy  consumed.  In  all  experiments  an  en¬ 
tity  is  spawned  and  migrates  with  the  moving  target.  En¬ 
tity  uniqueness  should  be  maintained  for  a  run  to  be  suc¬ 
cessful.  Hence,  we  count  the  number  of  entities  that  form 
around  the  moving  target  during  the  course  of  a  simulation 
to  determine  whether  or  not  our  architecture  was  success¬ 
ful  in  establishing  and  maintaining  a  single  entity  per  event. 
In  energy  cost  experiments,  we  compute  the  energy  con¬ 
sumed  during  send  and  receive  operations  in  accordance 
with  transmit  and  receive  currents  of  the  MICA  motes  [23]. 
CPU  energy  consumed  constitutes  a  constant  overhead. 

Each  point  in  the  graphs  below  represents  the  average  of  10 
runs  to  ensure  a  statistical  significance  at  the  0.05  level.  In 
the  subsequent  analysis  when  we  claim  a  target  is  trackable 
at  a  specified  speed  we  mean  that  for  all  10  trials,  a  sin¬ 
gle  entity  was  formed  and  tracked  during  each  trial.  The 
two  key  parameters  of  the  algorithm,  whose  settings  de¬ 
termine  performance  are  the  EMM  leader  heartbeat  period, 
and  the  awareness  horizon.  This  leader  heartbeat  period  de¬ 
fines  how  often  the  entity  leader  sends  heartbeats  to  mem¬ 
bers  (and  followers).  The  awareness  horizon,  in  our  exper¬ 
iments,  defines  how  many  hops  the  heartbeats  are  propa¬ 
gated.  Other  algorithm  parameters  are  automatically  com¬ 
puted  depending  on  the  settings  of  the  above  two.  Namely, 
we  require  that  the  failed  leader  timer  (used  to  detect  leader 
failure)  be  set  to  a  value  twice  greater  than  the  heartbeat  pe¬ 
riod  to  ensure  that  no  member  takes  over  leadership  while 
a  current  leader  is  still  sending  heartbeats.  Similarly  we  re¬ 
quire  that  the  entity  timeout  period  (used  to  free  follower 
nodes)  be  approximately  1 .5  times  the  failed  leader  period 

1  In  this  scenario  we  assume  that  our  sensory  horizon  is  radial 


to  ensure  that  no  follower  leaves  the  group  before  an  en¬ 
tity  member  could  properly  take  over  leadership  and  begin 
sending  heartbeats. 

Below,  we  present  and  discuss  those  parameters  that  we  feel 
are  most  influential  to  the  problem  addressed  and  the  so¬ 
lution  presented.  We  initially  start  with  those  parameters 
that  are  determined  by  the  network  or  otherwise  outside  of 
the  designer’s  control.  We  then  analyze  parameters  that  can 
be  set  by  the  designer.  For  these  graphs  we  choose  to  dis¬ 
play  the  heartbeat  timer  on  the  x-axis  to  analyze  its  affect  on 
chosen  metrics.  We  vary  the  range  of  hearbeat  values  from 
graph  to  graph  to  demonstrate  trends  in  the  timer  and  show 
what  we  feel  is  the  most  relevant  and  interesting  informa¬ 
tion  for  understanding  our  architecture’s  performance. 

4.2.1  Setting  Node  Density 

It  is  often  assumed  in  sensor  network  research  that  the  node 
density  is  high  enough  to  ensure  that  all  nodes  are  within 
communication  range  of  several  other  nodes  at  all  times. 
We  begin  by  understanding  the  effect  of  node  density  on 
the  performance  of  our  algorithm.  In  this  experiment,  we 
vary  the  number  of  nodes  in  the  rectangular  field,  and  ob¬ 
serve  the  number  of  formed  entities  around  the  moving  tar¬ 
get.  The  experiment  is  repeated  for  different  target  speeds. 
A  run  is  successful  if  only  one  entity  is  formed.  In  the  ex¬ 
periments  below,  we  choose  the  awareness  horizon  to  be 
one  hop,  which  as  we  show  later,  represents  a  worst  case 
from  the  perspective  of  trackability  at  the  target  speeds  con¬ 
sidered. 
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Figure  5.  Effect  of  node  density  on  number  of 
groups  formed  (heartbeat  period  =  375  msec, 
awareness  horizon  =  1  hop) 

Figure  5  demonstrates  the  results.  We  see  that  independent 
of  event  speed,  our  architecture  is  capable  of  maintaining 


the  formed  logical  entity  when  the  number  of  nodes  is  200 
or  higher  which  corresponds  to  an  average  distance  of  about 
140  meters  between  any  two  nodes.  Thus,  in  the  rest  of  this 
section  we  fixed  the  number  of  sensor  nodes  to  200,  as  a 
rough  estimate  of  “sufficient”  node  density. 

4.2.2  Effect  of  Leadership  Handoff 

Next,  we  explore  the  effect  of  the  leadership  handover 
mechanism  on  performance.  While  our  architecture  in¬ 
cludes  a  leadership  handoff  mechanism  that  explicitly  no¬ 
tifies  entity  members  when  a  new  leader  should  be  elected, 
we  compare  that  mechanism  to  the  case  where  the  old  leader 
simply  dies  in  which  case  a  timeout  must  elapse  before  the 
new  leader  election  starts.  Figures  6  and  7  compare  the  av¬ 
erage  number  of  entities  formed  around  the  target  for  differ¬ 
ent  target  speeds  with  and  without  the  handoff  mechanism 
respectively.  For  each  target  speed,  we  vary  the  leader  heart¬ 
beat  period.  Larger  periods  mean  that  more  time  will  elapse 
before  leader  failure  is  noticed.  Observe  that  the  curves  in 
Figure  6  are  generally  lower  than  in  Figure  7,  indicating 
a  larger  fraction  of  successful  runs.  Remember  that  each 
point  on  each  curve  is  the  average  of  10  runs.  Points  in¬ 
dicating  a  single  formed  entity  mean  that  all  10  runs  were 
successful.  The  handoff  mechanism  is  more  successful  in 
tracking  since  it  avoids  the  extra  delay  in  leadership  han¬ 
dover  making  it  less  likely  that  the  target  will  move  to  where 
it  can  be  sensed  outside  of  the  awareness  horizon,  thus  caus¬ 
ing  a  spurious  entity  to  emerge.  Thus,  in  the  rest  of  our 
analysis  we  only  consider  simulations  where  our  handoff 
mechanism  is  present. 
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Figure  6.  Groups  formed  with  our  explicit 
handoff  mechanism  (awareness  horizon  =  1 
hop) 


In  addition,  it  is  interesting  how  the  choice  of  the  heartbeat 


Heartbeat  Period  (msec) 


Figure  7.  Groups  formed  without  our  explicit 
handoff  mechanism  (awareness  horizon  =  1 
hop) 
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Figure  8.  Effect  of  timer  settings  on  message 
delay  (speed  =  1 2  m/s) 


period  strongly  influences  our  architecture’s  ability  to  track 
an  event.  Slow  periods  will  result  in  a  slower  transition  re¬ 
sulting  in  the  event  migrating  beyond  the  awareness  hori¬ 
zon.  Fast  periods  result  in  a  congested  channel  which  in¬ 
creases  message  loss  and  prevents  nodes  from  hearing  about 
an  approaching  event.  In  between  these  extremes,  an  opti¬ 
mal  choice  of  the  heartbeat  period  can  be  made.  This  choice 
will  be  investigated  in  more  detail  later  in  the  section. 

4.2.3  Limits  on  Heartbeat  Period 

Next,  we  analyze  the  overhead  of  the  algorithm  by  explor¬ 
ing  the  point  at  which  it  saturates  the  underlying  network. 
This  saturation  point  depends  on  the  setting  of  the  heart¬ 
beat  period  and  the  awareness  horizon.  It  is  fairly  obvi¬ 
ous  that  decreasing  the  heartbeat  period  results  in  more  fre¬ 
quent  communication  between  the  nodes  and  therefore  the 
ability  to  track  faster  targets.  This  is  based  simply  on  the 
speed  of  response  necessary  for  faster  targets.  However,  the 
bandwidth  limitations  in  the  wireless  medium  place  limits 
on  our  timer  settings  and  constrain  our  architecture’s  abil¬ 
ity  to  track  migrating  events.  To  determine  the  bandwidth 
needs  of  our  algorithm  we  decrease  the  leader  heartbeat  pe¬ 
riod  and  observe  the  resulting  connection  delay,  which  is 
the  time  it  takes  to  send  a  message  from  the  moving  entity 
to  the  friendly-force  entity.  When  the  network  approaches 
saturation,  a  sharp  increase  in  delay  is  observed.  Figure  8 
shows  this  effect.  The  experiment  is  repeated  for  different 
awareness  horizons,  expressed  in  the  number  of  hops  that 
leader  heartbeats  are  propagated  to.  It  is  seen  that  when  the 
horizon  is  increased,  the  onset  of  overload  occurs  earlier  as 
more  messages  are  communicated. 


From  Figure  8  we  can  see  that  the  bandwidth  of  the  wire¬ 
less  medium  is  fully  saturated  when  the  leader  heartbeat  pe¬ 
riod  is  reduced  to  approximately  2.9,  5.9,  and  11.7  msec 
for  an  awareness  horizon  of  =  1,  2,  and  3  hops  respec¬ 
tively.  To  conservatively  avoid  this  saturation  point  and  en¬ 
sure  enough  bandwidth  is  left  for  alternate  local  traffic,  we 
multiply  these  numbers  by  5  (i.e.,  limit  the  worst  case  over¬ 
head  of  tracking  to  20%).  Hence,  in  the  rest  of  the  evalua¬ 
tion  section,  we  consider  only  those  leader  heartbeat  periods 
that  are  above  12.5,  25,  and  50  msec  for  1,  2,  and  3  hops  re¬ 
spectively.  We  next  turn  our  attention  to  the  selection  of 
the  leader  heartbeat  period  and  the  awareness  horizon,  the 
two  key  parameters  of  the  algorithm,  subject  to  the  above 
constraints. 

4.2.4  Heartbeat  Period  and  Awareness  Horizon  Trade¬ 
offs 

Our  group  management  protocol  works  by  propagating 
leader  heartbeats  a  specified  number  of  hops  from  the 
leader,  which  determines  the  awareness  horizon.  Increasing 
the  hop  count  allows  us  to  track  faster  events  since  it  extends 
the  area  in  which  nodes  know  about  the  oncoming  event  and 
requires  a  faster  event  to  migrate  faster  than  its  correspond¬ 
ing  logical  entity.  However  as  previously  mentioned,  the 
awareness  horizon  restricts  the  maximum  leader  heartbeat 
period,  another  important  parameter  of  the  algorithm.  In  the 
following  experiment,  we  study  the  coupling  between  these 
parameters  to  analyze  their  affect  on  the  maximum  track- 
able  event  speed.  Specifically,  we  vary  the  leader  heart¬ 
beat  period  over  a  range  above  the  pre-determined  satu¬ 
ration  points,  and  compute  for  each  period  the  maximum 
event  speed  at  which  tracking  always  succeeds  in  maintain- 
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ing  a  single  entity  for  the  moving  target.  A  different  curve 
is  plotted  for  different  awareness  horizons. 


Figure  9.  Trackable  event  speeds  for  varied 
heartbeat  period :awareness  horizon  settings 


Figure  9  shows  the  results  of  the  above  experiment.  Fol¬ 
lowing  the  curves  from  right  to  left,  we  can  see  that  up  to 
a  threshold,  reducing  the  leader  heartbeat  period  results  in 
the  ability  to  track  faster  events.  However,  at  this  threshold, 
network  collisions,  congestion,  and  message  loss  become 
dominant.  Hence,  the  maximum  trackable  speed  deterio¬ 
rates.  This  is  apparent  from  the  sudden  drop  in  the  maxi¬ 
mum  trackable  speed  seen  on  the  far  left  side  of  the  graph 
(about  100  msec).  We  also  note  that  increasing  the  aware¬ 
ness  horizon  increases  the  trackable  speed  for  slower  heart¬ 
beats,  but  also  congests  the  channel  faster  resulting  in  an 
inability  to  track  faster  targets.  In  the  graph  we  notice  that 
the  single  hop  awareness  horizon  remains  below  the  2  and 
3  hop  settings  up  until  about  400  msec,  the  point  at  which 
all  but  the  1  hop  settings  begin  to  break  down. 

A  designer’s  decision  to  set  the  heartbeat  period  and  the 
awareness  horizon  should  be  guided  by  the  limitations  on 
trackable  speed  shown  in  Figure  9.  The  trends  seen  in  this 
figure  illustrate  the  fundamental  trade-offs  involved  in  pa¬ 
rameter  selection  in  our  algorithm.  While  the  axes  can  be 
scaled  depending  on  other  platform  settings  such  as  node 
spacing,  the  figure  provides  interesting  insights  into  the 
choice  of  protocol  settings.  For  example,  the  figure  shows 
that  for  speeds  lower  than  120  m/s  (i.e.,  slightly  more  than 
half  our  communication  radius  per  second)  a  designer  has 
a  choice  of  heartbeat  period  and  awareness  horizon  settings 
that  jointly  allow  a  given  speed  to  be  tracked.  The  candi¬ 
date  settings  are  those  that  result  from  intersecting  a  hor¬ 
izontal  line  (drawn  at  the  desired  speed)  with  each  of  the 
three  plots  representing  the  different  awareness  horizons. 
Each  intersection  point  gives  the  heartbeat  period  needed 


for  the  corresponding  awareness  horizon.  In  general,  choos¬ 
ing  a  larger  awareness  horizon  implies  a  more  relaxed  (i.e., 
larger)  heartbeat  period.  For  example,  to  track  a  target  of 
speed  50  m/s,  one  can  use  a  heartbeat  period  of  1600,  2900, 
and  4200  msec  for  a  horizon  of  1,  2,  and  3  hops  respectively. 
Interestingly,  observe  from  Figure  8  that  at  those  periods 
the  network  is  fairly  underloaded.  When  the  target  speed 
is  higher  than  120  m/s,  however,  larger  values  of  awareness 
horizon  fail,  since  they  present  a  higher  percentage  of  mes¬ 
sage  loss  and  larger  delays  which  allow  spurious  entities  to 
be  created.  At  those  speeds  a  smaller  awareness  horizon  is 
necessary. 

If  the  designer  has  multiple  choices,  an  important  factor  in 
choosing  a  particular  combination  of  parameters  is  power 
consumption.  The  effect  of  parameter  settings  on  power 
consumption  is  explored  next. 

4.2.5  Effect  of  Leader  Heartbeat  Period  and  Aware¬ 
ness  Horizon  on  Energy  Consumption 

Aside  from  their  influence  on  the  maximum  trackable 
speed,  the  leader  heartbeat  period  and  the  awareness  hori¬ 
zon  also  significantly  influence  message  related  energy  con¬ 
sumption.  For  different  hardware  this  effect  will  vary.  How¬ 
ever,  the  fundamental  trends  remain  consistent. 
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Figure  10.  Energy  consumption  for  varied 
heartbeat  period :awareness  horizon  pairs 

Figure  10  shows  energy  consumption  for  varying  the  leader 
heartbeat  period  and  awareness  horizons  explored  in  Figure 
9.  The  effect  of  the  heartbeat  period  on  energy  consumption 
is  significant.  An  interesting  point  to  notice,  however,  is  that 
the  alternative  (horizon,  period)  tuples  that  track  a  particular 
speed  consume  almost  the  same  amount  of  energy.  Follow¬ 
ing  up  on  the  example  from  the  previous  section,  the  three 
alternative  parameter  tuples  that  track  a  speed  of  50  m/s. 
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namely,  (1  hop,  1600  msec),  (2  hops,  2900  msec),  and  (3 
hops,  4200  msec),  consume  roughly  the  same  energy  of  4 
units.  This  is  seen  by  finding  the  intersections  of  the  ver¬ 
tical  lines  at  1600  msec,  2900  msec  and  4200  msec  with 
the  energy  curves  for  the  corresponding  horizon.  It  there¬ 
fore  appears  that  choosing  a  larger  horizon  does  not  have  an 
advantage  as  long  as  the  heartbeat  period  is  appropriately 
chosen.  This  is  not  counter-intuitive.  Increasing  the  aware¬ 
ness  horizon  allows  using  a  larger  heartbeat  period.  How¬ 
ever,  it  also  increases  the  number  of  messages  sent,  since 
each  heartbeat  is  flooded  in  a  larger  radius.  The  net  sum  of 
messages  exchanged,  therefore,  remains  largely  unaffected. 

In  view  of  the  above,  an  argument  can  be  made  for  smaller 
horizons,  since  they  reduce  the  number  of  nodes  inhibited 
from  creating  new  entities,  thus  making  the  sensor  network 
more  responsive  to  the  advent  of  new  events  into  the  envi¬ 
ronment.  Nodes  in  a  network  with  a  large  awareness  hori¬ 
zon  will  attribute  measurements  of  such  new  events  to  the 
entities  they  are  already  aware  of;  an  effect  that  should  be 
avoided. 

The  set  of  experiments  presented  above  illustrate  the  ability 
of  our  architecture  to  track  events  at  varied  speeds  in  a  suf¬ 
ficiently  dense  sensor  network.  A  system  designer  can  em¬ 
ploy  this  architecture,  choosing  the  leader  heartbeat  period 
and  the  awareness  horizon  in  accordance  with  the  expected 
speed  of  migrating  events,  available  bandwidth  of  the  wire¬ 
less  medium,  and  energy  restrictions  (required  system  life¬ 
time)  of  the  hardware  being  deployed.  An  implementation 
of  our  architecture  on  the  MICA  motes  which  is  discussed 
in  the  following  section. 

5  Motes  Implementation 


We  implemented  our  work  on  the  MICA  motes  developed 
by  X-Bow.  Under  our  architecture  we  implemented  a  sim¬ 
ple  Geographic  Forwarding  [16]  mechanism  as  well  as  a 
simple  buffering  MAC  protocol  that  follows  a  send  when 
ready  strategy  with  no  contention  resolution.  See  [11]  for 
more  information  on  the  MICA  platform  and  TinyOS  Oper¬ 
ating  System. 

Our  MICA  test  bed  consists  of  24  motes  laid  out  in  a  12  X 
2  grid  with  motes  placed  one  foot  apart.  Nodes  communi¬ 
cate  to  neighboring  nodes  within  a  specified  neighborhood 
grid  size  (NGS).  The  awareness  horizon  is  set  to  1  hop  in 
accordance  with  the  small  size  of  the  network.  For  our  ex¬ 
periments  we  tested  NGS  sizes  of  2  and  4. 

Nodes  are  employed  with  light  sensors  capable  of  detecting 
a  shadow  cast  by  the  tracked  event.  Our  goal  was  to  track  a 
rectangular  object  1  square  grid  in  size,  moving  at  a  speed 
of  1  grid  per  10  seconds  (GrPS).  Nodes  are  programmed 
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Table  1.  Entities  formed  over  varied  event 
speeds  on  the  MICA  testbed 


with  our  tracking  architecture  and  an  application  which  per¬ 
forms  target  location  estimation.  Additionally,  nodes  are 
pre-configured  to  report  a  detected  event  to  a  fixed  loca¬ 
tion  in  the  sensor  network  (node  0)  every  time  the  aggregate 
event  location  changes. 

Based  on  the  limited  bandwidth,  energy  restrictions,  ex¬ 
pected  target  speed,  and  radio  radius  of  the  MICA  motes, 
we  experimented  with  and  chose  our  heartbeat,  failed 
leader,  and  entity  timeout  timers  to  be  2,  5,  and  8  seconds 
respectively. 
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Figure  11.  Reported  location  of  tracked  entity 
on  MICA  motes  (Speed  =  1/10  GrPS,  NGS=4) 


Initial  experimental  data  show  that  for  speeds  of  1/10,  and 
1/15  GrPS  and  a  NGS  of  4  grids,  our  architecture  as  de¬ 
ployed  was  capable  of  correctly  forming,  maintaining,  and 
reporting  the  location  of  a  group  around  the  event  of  in¬ 
terest.  The  reported  path  of  the  event  for  one  such  trial  is 
shown  in  Figure  11.  The  path’s  jagged  quality  is  a  result 
of  the  limited  number  of  motes  detecting  and  reporting  a 
position  for  the  target  at  any  specific  point  in  time.  It  is  pos¬ 
sible  that  when  the  communication  radius  and  the  speed  of 
events  vary,  multiple  groups  can  be  formed.  Table  1  shows 
the  number  of  groups  formed  over  different  speeds  in  the 
MICA  testbed.  The  creation  of  spurious  groups  at  faster 
speeds  is  due  largely  to  the  use  of  an  unreliable  MAC  layer 
in  the  experiments.  Message  loss,  as  mentioned  in  the  pa¬ 
per,  allows  spurious  entities  to  be  created.  The  noisy  nature 
of  the  measured  track  is  due  to  the  fact  that  the  used  light 
sensors  do  not  provide  a  measure  of  distance  from  the  tar¬ 
get.  Hence,  the  best  one  can  do  is  simply  average  the  po¬ 
sitions  of  all  sensors  detecting  the  event.  In  contrast,  other 
sensors  (such  as  magnetic  senors)  can  provide  a  better  es¬ 
timate  of  how  far  a  measured  target  is.  Triangulation  will 
therefore  result  in  a  much  more  accurately  estimated  posi¬ 
tion. 

Observe  that  the  purpose  of  our  experimental  measurements 
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is  to  qualitatively  illustrate  the  success  of  our  scheme  in 
practice.  It  is  not  our  purpose  to  compare  experimental  mea¬ 
surements  to  simulation.  We  have  purposely  decided  to  use 
a  standard  wireless  MAC  layer  in  the  simulator  instead  of 
the  simplified  unreliable  custom  MAC  layer  implemented 
on  the  actual  motes.  Consequently,  different  performance 
results  are  expected.  We  believe  that  the  implementation  of 
the  motes  MAC  layer  will  mature  significantly  in  the  future, 
making  it  less  interesting  to  seek  quantitative  performance 
statements  on  the  current  testbed  at  this  time. 

6  Conclusions  and  Future  Work 

In  this  work  we  provide  a  transport  layer  solution  to  en¬ 
tity  maintenance  and  connectivity  in  sensor  networks.  Our 
proposed  middleware  service  provides  a  novel  way  for  pro¬ 
grammers  to  relate  to  events  in  the  environment  without 
concern  for  topological  and  communication  layer  details 
impertinent  to  their  application.  We  establish  entities  in  a 
one-to-one  relationship  with  events  to  ensure  correct  and 
well  defined  behavior.  Entities  form  and  register  with  inter¬ 
ested  parties  to  allow  unique  identification  and  communica¬ 
tion  without  regard  for  an  event’s  location. 

The  analysis  of  our  architecture  demonstrates  the  effect  of 
both  uncontrollable  (environment  specific )  and  controllable 
(architecture  specific)  parameters  on  entity  formation  and 
maintenance.  In  accordance  with  an  ideal  sensor  network, 
we  require  that  at  any  time  at  least  one  node  is  capable  of 
sensing  the  event  being  tracked.  Under  this  assumption  we 
demonstrate  our  architectures  capabilites  and  limitations  in 
tracking  events  of  varied  speeds  as  a  function  of  the  pre¬ 
specified  heartbeat  and  awareness  horizon  parameters.  For 
a  large  field  of  relatively  dense  nodes,  we  show  in  simula¬ 
tion  that  our  architecture  is  capable  of  tracking  events  that 
travel  over  half  of  the  communication  radius  of  a  node  per 
second  (see  Figure  9).  We  additionally  discuss  the  required 
settings  for  tracking  events  of  varied  speeds  and  the  tradeoff 
of  increasing  the  trackable  speed  and  thereby  increasing  the 
amount  of  energy  consumed. 

In  addition  to  simulation  analysis,  we  provide  an  implemen¬ 
tation  of  our  architecture  on  the  MICA  test  bed  in  our  lab. 
In  the  presence  of  true  fading  and  message  loss  we  demon¬ 
strate  the  feasability  of  our  work  for  a  simple  application. 

While  our  architecture  provides  the  required  mechanisms  to 
create,  maintain,  and  communicate  with  abstract  entities  in 
an  environment,  we  have  only  begun  to  explore  the  possi¬ 
bilities  of  such  sensor  network  related  services.  In  addition 
to  studying  and  optimizing  the  modules  of  our  current  solu¬ 
tion,  we  plan  to  extend  our  architecture  into  new  paradigms 
of  computing  in  such  environments.  Self-adaptive  mech¬ 
anisms  for  fine  tuning  architectural  parameters,  as  well  as 
support  for  real-time  requirements  provide  just  a  start  to 


what  is  possible  for  architectural  optimizations  and  exten¬ 
sions.  New  programming  paradigms  could  include  spawn¬ 
ing  abstract  entities  of  interest  that  go  beyond  a  group  of 
nodes’  local  sensor  readings.  Additionally  we  need  to  an¬ 
alyze  the  inherent  limitations  of  real  sensor  network  sys¬ 
tems,  both  from  a  hardware  and  software  perspective,  to  en¬ 
sure  theoretical  work  translates  well  into  our  test-bed.  The 
applications  and  opportunities  for  sensor  networks  remain 
vast  and  mostly  unexplored.  This  paper  is  a  step  towards 
a  comprehensive  coverage  of  research  issues  motivated  by 
tracking  problems  in  such  networks. 
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